REMARKS; 

Claims 1, 14-28 and 30-60 are pending in the application. Claims 1, 28 and 48 have been 
amended hereby. Claims 49-60 are new. Claims 2-13 and 29 have peen previously cancelled 
(without prejudice or disclaimer). 

Reconsideration is respectfully requested of the rejection of claims 1, 18, 28 and 48 under 
35 U.S.C. 1 12, first paragraph, as allegedly failing to comply with the enablement requirement. 

Initially, it is noted that applicants respectfully disagree with the Examiner's analysis of 
these claims and the disclosure of the specification with regard to enablement. 

Nevertheless, in order to expedite prosecution of the application, the "customizing the 
user interface" wording that the Examiner had taken issue with has been replaced with alternative 
wording which is more clearly disclosed in the specification. 

Therefore, it is respectfully submitted that the rejection of claims 1, 18, 28 and 48 under 
35 U.S.C. 1 12, first paragraph, has been overcome. 

Reconsideration is respectfully requested of the rejection of claims 1, 14-28 and 30-48 
under 35 U.S.C. 103(a) as being unpatentable over U.S. Patent No. 6,385,655 ("Smith et al.") in 
view of U.S. Patent No. 6,442,571 ("Haff et al.") and U.S. Patent No. 5,815,665 ("Teper et al."). 

Initially, it is noted that applicants respectfully disagree with the Examiner's analysis of 
the claims of the application and the Smith et al., Haff et al. and Teper et al. references. 

For example, applicants respectfully disagree with the Examiner's conclusion to the 
effect that it would have somehow been obvious to combine Smith et al., Haff et al. and Teper et 
al. as suggested by the Examiner. 

Moreover, it is respectfully submitted that even if the references were combined, the 
resulting combination would still fail to teach, show or suggest the currently claimed invention. 

In this regard, the present invention, as recited in independent claims 1, 28 and 48, relates 
to interchanging documents between a sender computer and a plurality of receiver computers. Of 
note, each of the independent claims recites that a notification message is customized based on a 
respective selected recipient and the customization of each notification message includes a 
mechanism for retrievin g a customized user interface for each selected recipient . 

Smith et al. relates to a method and apparatus for delivering documents over an electronic 
network while preserving document formatting. A document is sent from a sending computer to a 
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dedicated server, using a send client application. The document is specified for delivery within 
the send client application, or by clicking and dragging the document onto an appropriate 
window or icon on the sending computer desktop, or is specified from within a document 
authoring application. A dedicated server stores the document and forwards an electronic 
notification to a receiving device. The stored document is downloaded from the dedicated server, 
using a receive client application, in response to the notification. The receive client application 
permits the recipient to receive, view, print, and/or manipulate the document. The dedicated 
server is managed by a configuration user interface having an HTML interface for sending, 
tracking, accessing account information, managing billings, and managing mail distribution lists. 
The send client application allows a user to specify document delivery parameters. The 
parameters may be stored for later modification and/or use. 

Regarding the above-mentioned configuration user interface, Smith et al. indicates, at 
Col. 10, lines 45-67, that: 

A configuration user interface is provided for directly invoking and customizing the 
dedicated server. The CUI is accessed via a CUI application window displayed on a 
managing computer desktop. Alternatively, the CUI is accessed through any Web browser 
application that supports tables, or accessed through the send client application. FIG. 6 is 
a view of a CUI application window 140 according to the preferred embodiment of the 
invention. 

In the preferred embodiment of the invention, the CUI is an HTML interface for invoking 
and customizing the dedicated server via a Web browser. This HTML interface includes 
modules for sending the document, tracking the document, accessing information 
associated with the document delivery account, managing billings for the document 
delivery, and managing mail distribution lists. 

The CUI offers different sets of functions, depending on the user and type of account 
used. Individual account holders, group account managers, and group members see 
slightly different interfaces and are able to access and manipulate varying sets of data. 
When a user initiates a CUI session, the type of account is identified by the dedicated 
server. The specific user is then provided with the appropriate functions and data. 

Thus, while Smith et al. does describe slightly different interfaces for different types of 
people, this reference fails to teach, show or suggest that a notification message is customized 
based on a respective selected recipient and the customization of each notification message 
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includes a mechanism for retrieving a customized user interface for each selected recipient . 

Regarding Haff et al., this reference relates to a computer data signal embodied in a 
propagation medium. The signal enables a variable number of data transfers and includes an 
initial connection source code segment and a data transfer source code segment. The initial 
connection source code segment establishes a connection between at least two devices via 
predetermined listening ports, with at least one predetermined listening port residing within each 
device. The initial connection source code segment also dynamically assigns a first data port 
within a first device, and transmits the address of the first data port to a remaining device via the 
predetermined listening ports. The data transfer source code segment is for each of the variable 
number of data transfer operations. The data transfer source code segment dynamically assigns a 
corresponding second data port within the remaining device and transfers data between the 
connected devices via the data ports so that the data is substantially simultaneously transferred 
between a variable number of devices via the data ports. Each pair of first and second data ports 
is established in response to each listening port connection. 

Here again, this reference fails to teach, show or suggest that a notification message is 
custo mized based on a respective selected recipient and the customization of each notification 
message includes a mechanism for retrieving a customized user interface for each selected 
recipient . 

Finally, regarding Teper et al, this reference relates to an Online Brokering Service that 
provides user authentication and billing services to allow users to anonymously and securely 
purchase online services from Service Providers (SP) sites (e.g., World Wide Web sites) over a 
distributed public network, which may be an untrusted public network such as the Internet. Users 
and SP sites initially register with the Brokering Service, and are provided with respective client 
and server software components for using the Brokering Service. In one embodiment, when a 
user initially connects to an SP site, the SP site transmits a challenge message over the public 
network to the user computer, and the user computer generates and returns and cryptographic 
response message (preferably generated using a password of the user). The SP site then passes 
the response message to the Brokering Service, which in-turn looks up the user's password and 
authenticates the response message. If the response message is authentic, the Online Brokering 
Service transmits an anonymous ID to the SP site, which can be used for subsequently billing the 
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user. In addition, the Online Brokering Service transmits user-specific access rights data to the 
SP site, allowing the SP site to customize its services for the particular user. Billing events 
generated by the SP sites are transmitted to the Brokering Service, which maintains a user- 
viewable bill that shows all charges from all SP sites accessed by the user. The payment 
information (e.g., credit card number) and other personal information of users are not exposed to 
the SP sites, and are not transmitted over the distributed network. 

To the extent customization is carried out, such customization is carried out by the 
service provider's WWW site. This is discussed, for example, at Col. 17, line 64 to Col. 18, line 
23: 

With reference to blocks 108 and 110, if the Brokering Agent determines that 
the response message was properly generated, and is thus (presumably) 
authentic, the Brokering Agent 62 accesses the accounts database 64B to obtain 
the user-specific customization information (e.g., display preferences, 
connection speed, geographic region, etc.), if any, to be provided to the WWW 
site 50 with the subsequent verification message. In addition, the Brokering 
Agent 62 queries the MSN security system (as indicated by arrow "F" in FIG. 4) 
for the user's access rights with respect to the WWW site 50. This effectively 
involves a two-step process: First, the user's token list is obtained from the 
security database. This token list may include tokens (and corresponding access 
right data) which correspond to other service areas, such as internal MSN service 
areas and/or service areas of other SP sites 50. Second, the token list is filtered 
by retaining only those tokens to which the particular Service Provider making 
the authentication request has sysop privileges. The result is a filtered token list 
which specifies the user's access rights only with respect to the particular WWW 
server 50. 

As indicated above, the steps corresponding to blocks 108 and 1 10 represent 
optional features which need not be used by the Service Providers. Accordingly, 
it is contemplated that the pass-through message will include a field for allowing 
the WWW server 50 to specify (1) the customization data to be returned, if any, 
and (2) whether the user's access rights should be returned. 

Regardless of any such customization, however, this reference fails to cure the deficiency 
of Smith et al. noted above in connection with the claimed feature directed to a notification 
message being customized based on a r e spective selected recipient and the customization of each 
notification message including a mechanism for retrieving a customized user interface for each 
selected recipient . 
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Therefore, since the above-mentioned customization feature is not taught, shown or 
suggested by Smith et al., Haff et al. or Teper et al. (either alone or in combination), it is 
respectfully submitted that the rejection of claims 1, 28 and 48 has been overcome. 

Moreover, it is noted that claims 14-27 depend from independent claim 1. Thus, it is 
respectfully submitted that these claims are patentably distinct for at least the same reasons as 
claim 1. 

Likewise, it is noted that claims 30-47 depend from independent claim 28. Thus, it is 
respectfully submitted that these claims are patentably distinct for at least the same reasons as 
claim 28. 

In addition, it is respectfully submitted that a number of dependent claims are patentably 
distinct based upon additional subject matter recited therein. 

For example, regarding claims 15 and 31, the Examiner asserts that Smith et al. disclose, 
at col. 3, lines 20-36, that the uploading of the document stored in the sender computer storage 
means further comprises uploading the document at predetermined time intervals. 

In this regard, col. 3, lines 20-36 of Smith et al. state that: 

A package manager and a package window are also accessed from the application 
window. The package manager lists all document activities initiated during an application 
session. The package window allows the user to specify parameters of the document 
delivery, including the recipient(s), the document(s), and send options. Document 
delivery parameters may be stored in a storage module for later modification and/or use. 

A document is specified for delivery in several ways. The user can click and drag the 
document from the sending computer desktop onto one of the application window or the 
package window. The document may also be dragged onto either the icon representing 
the send client application or the icon for accessing the stored document delivery 
parameters. The user can also browse local and network directories and select desired 
documents. A document can also be sent from within a document authoring application. 

It is respectfully submitted that such disclosure of Smith et al. (e.g., discussing a package 
window which allows the user to specify parameters of the document delivery) simply does not 
show or suggest the explicitly claimed uploading of the document at predetermined time 
intervals . 

Further, regarding claims 16 and 32, the Examiner asserts that Haff et al. disclose, at col. 
9, lines 1-23, that the respective notification message includes data indicative of new documents 
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uploaded into the server storage means from the sender computer storage means since the 
issuance of a previous respective notification message. 

In this regard, col. 9, lines 1-23 of Haff et al. state that: 



The signal may also include a certifying source code segment that communicates with an 
independent certifying processor that verifies return receipts for point of origin, 
destination, and successful completion information. The independent certifying processor 
sends verification certification to the device that originated the data transfer upon 
successful completion of the data transfer. The return receipt source code segment also 
generates and sends a return receipt from the device that received the data transfer to the 
independent certifying processor upon successful completion of the data transfer. 

Preferably socket data structures are dynamically managed and each data port is 
represented by a socket data structure. Further, each device may store the socket data 
structures in a linked list in order to manage the flow of data transfers. The linked list is 
traversed to enable substantially simultaneous data transfers. 

The signal may also include a credit source code segment that maintains and monitors 
data transfer credits and detects each data transfer in order to deduct credit from a credit 
account after a successful data transfer. The data transfer is only permitted when the 
device initiating the transfer has sufficient credits. 



It is respectfully submitted that such disclosure of Haff et al. (e.g., discussing receipts for 
point of origin, destination, and successful completion information) simply does not show or 
suggest the claimed notification message including data indicative of new documents uploaded 
into the server storage means from the sen d er computer storage means since the issuance of a 
previous respective notification messag e. 

Further still, regarding claims 27 and 41, the Examiner asserts that Smith et al. disclose, 
at col. 8, lines 1-15, that the association of an email address with each of the recipients further 
comprises adding a security designation to each email address of each recipient. 

In this regard, col. 8, lines 1-15 of Smith et al. state that: 

Any number of recipients or mail lists for a given delivery are specified in the "To:" field 
110 of the package window. Each recipient must be specified by an E-mail address, alias, 
or mail list. The user may type an address directly into the "To:" field. Alternatively, the ' 
user may access a recipients window by clicking on the "To:" button 1 08. 
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The subject of the message is entered into the subject field 134. The message itself is 
entered into the message field 136. The subject 134 and message 136 fields are optional. 
In the preferred embodiment of the invention, the subject appears in the E-mail 
notification message and on an HTML cover page for the downloaded document. The 
message appears only in the E-mail notification. 

It is respectfully submitted that such disclosure of Smith et al. (e.g., discussing filling-out 
the "To:", subject and message fields) simply does not show or suggest that the claimed 
association of an email address with each of the recipients further comprises adding a security 
designation to each email address of each recipient. 

Therefore, in view of the above detailed discussion, it is respectfully submitted that the 
rejection of claims 1, 14-28 and 30-48 under 35 U.S.C. 103(a) as being unpatentable over Smith 
et al. in view of Haff et al. and Teper et al. has been overcome. 

Moreover, the Examiner's attention is directed to new claims 49-60. Each of these new 
claims 49-60 depends (directly or indirectly) from one of independent claims 1, 28 and 48. Thus, 
each of these new claims 49-60 is submitted to be patentably distinct for at least the same reasons 
as the claim from which it depends. 

In addition, a number of these new claims are submitted to recite additional patentably 
distinct subject matter. 

For example, claims 51, 55 and 59 recite that the customized user interface for each 
selected recipient makes it app ear that each selected recipient is connected to an internal client 
server distinct from the server from w h ich the notification message was issued . This feature is 
nether taught, shown or suggested by any of the cited references. 

In another example, claims 52, 56 and 60 recite that the customized user interface for a 
first one of the selected recipients make s it appear that the first one of the selected recipients is 
connected to a first company server asso c iated with a first company , wherein the customized user 
interface for a second one of the selec ted recipients makes it appear that the second one of the 
selected recipients is connected to a s e cond company server associated with a second comp any. 
and wherein the first company and the second company are distinct from one another . 

Finally, it is noted that this Amendment is fully supported by the originally filed 
application and thus, no new matter has been added. For this reason, the Amendment should be 
entered. 
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For example, support for the amendments to claims 1, 28 and 48 is found at page 9, lines 
11-14; page 14, lines 19-23; in Figs. 7-11; and throughout the specification. 

Further, support for new claims 49, 53 and 57 is found, for example, at page 12, lines 3- 
16; in Fig. 9; and throughout the specification. 

Further still, support for new claims 50, 54 and 58 is found, for example, at page 12, lines 
3-16; in Fig. 9; and throughout the specification. 

Further still, support for new claims 51, 55 and 59 is found, for example, at page 9, lines 
1 1-14; in Figs. 7-11; and throughout the specification. 

Further still, support for new claims 52, 56 and 60 is found, for example, at page 8, lines 
22-26; page 9, lines 11-14; in Figs. 7-11; and throughout the specification. 

Accordingly, it is respectfully submitted that each rejection raised by the Examiner in the 
April 3, 2006 Office Action has been overcome and that the above-identified application is now 
in condition for allowance. 

Favorable reconsideration is earnestly solicited. 



Respectfully submitted, 
GREENBERG TRAURIG 

Dated: September 29, 2006 By: /Matthew B. Trooper/ 

Matthew B. Tropper 
Registration No. 37,457 

Mailing Address: 
GREENBERG TRAURIG 
MetLife Building 
200 Park Avenue 
New York, NY 10166 
(212) 801-2100 
Facsimile: (212) 801-6400 
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